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Locator/ID Separation Protocol (LISP) Map-Server Interface 
Abstract 


This document describes the Mapping Service for the Locator/ID 
Separation Protocol (LISP), implemented by two new types of LISP- 
speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that 
provides a simplified "front end" for one or more Endpoint ID to 
Routing Locator mapping databases. 


By using this service interface and communicating with Map-Resolvers 
and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel 
Routers are not dependent on the details of mapping database systems, 
which facilitates experimentation with different database designs. 
Since these devices implement the "edge" of the LISP infrastructure, 
connect directly to LISP-capable Internet end sites, and comprise the 
bulk of LISP-speaking devices, reducing their implementation and 
operational complexity should also reduce the overall cost and effort 
of deploying LISP. 


Status of This Memo 
This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 


evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering 


Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not 


all documents approved by the IESG are a candidate for any level of 
Internet Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6833. 
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(http://trustee.ietf.org/license-info) in effect on the date of 
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to this document. Code Components extracted from this document must 
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1. Introduction 


The Locator/ID Separation Protocol [RFC6830] specifies an 
architecture and mechanism for replacing the addresses currently used 
by IP with two separate name spaces: Endpoint IDs (EIDs), used within 
sites; and Routing Locators (RLOCs), used on the transit networks 
that make up the Internet infrastructure. To achieve this 
separation, LISP defines protocol mechanisms for mapping from EIDs to 
RLOCs. In addition, LISP assumes the existence of a database to 
store and propagate those mappings globally. Several such databases 
have been proposed; among them are the Content distribution Overlay 
Network Service for LISP (LISP-CONS) [LISP-CONS], LISP-NERD 

(a Not-so-novel EID-to-RLOC Database) [RFC6837], and LISP Alternative 
Logical Topology (LISP+ALT) [RFC6836]. 
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The LISP Mapping Service defines two new types of LISP-speaking 
devices: the Map-Resolver, which accepts Map-Requests from an Ingress 
Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a 
mapping database; and the Map-Server, which learns authoritative 
EID-to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes 
them in a database. 


Conceptually, LISP Map-Servers share some of the same basic 
configuration and maintenance properties as Domain Name System (DNS) 
[RFC1035] servers; likewise, Map-Resolvers are conceptually similar 
to DNS caching resolvers. With this in mind, this specification 
borrows familiar terminology (resolver and server) from the DNS 
specifications. 


Note that while this document assumes a LISP+ALT database mapping 
infrastructure to illustrate certain aspects of Map-Server and 
Map-Resolver operation, the Mapping Service interface can (and likely 
will) be used by ITRs and ETRs to access other mapping database 
systems as the LISP infrastructure evolves. 


Section 5 of this document notes a number of issues with the 
Map-Server and Map-Resolver design that are not yet completely 
understood and are subjects of further experimentation. 


The LISP Mapping Service is an important component of the LISP 
toolset. Issues and concerns about the deployment of LISP for 
Internet traffic are discussed in [RFC6830]. 


2. Definition of Terms 


Map-Server: A network infrastructure component that learns of 
EID-Prefix mapping entries from an ETR, via the registration 
mechanism described below, or some other authoritative source if 
one exists. A Map-Server publishes these EID-Prefixes ina 
mapping database. 


Map-Resolver: A network infrastructure component that accepts LISP 
Encapsulated Map-Requests, typically from an ITR, and determines 
whether or not the destination IP address is part of the EID 
namespace; if it is not, a Negative Map-Reply is returned. 
Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC 
mapping by consulting a mapping database system. 
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Encapsulated Map-Request: A LISP Map-Request carried within an 
Encapsulated Control Message, which has an additional LISP header 
prepended. Sent to UDP destination port 4342. The "outer" 
addresses are globally routable IP addresses, also known as RLOCs. 
Used by an ITR when sending to a Map-Resolver and by a Map-Server 
when forwarding a Map-Request to an ETR. 


Negative Map-Reply: A LISP Map-Reply that contains an empty 
Locator-Set. Returned in response to a Map-Request if the 
destination EID does not exist in the mapping database. 
Typically, this means that the "EID" being requested is an IP 
address connected to a non-LISP site. 


Map-Register message: A LISP message sent by an ETR to a Map-Server 
to register its associated EID-Prefixes. In addition to the set 
of EID-Prefixes to register, the message includes one or more 
RLOCs to be used by the Map-Server when forwarding Map-Requests 
(re-formatted as Encapsulated Map-Requests) received through the 
database mapping system. An ETR may request that the Map-Server 
answer Map-Requests on its behalf by setting the "proxy Map-Reply" 
flag (P-bit) in the message. 


Map-Notify message: A LISP message sent by a Map-Server to an ETR 
to confirm that a Map-Register has been received and processed. 
An ETR requests that a Map-Notify be returned by setting the 
"want-map-notify" flag (M-bit) in the Map-Register message. 
Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both 
source and destination. 


For definitions of other terms -- notably Map-Request, Map-Reply, 
Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please 
consult the LISP specification [RFC6830]. 


3. Basic Overview 


A Map-Server is a device that publishes EID-Prefixes in a LISP 
mapping database on behalf of a set of ETRs. When it receives a Map 
Request (typically from an ITR), it consults the mapping database to 
find an ETR that can answer with the set of RLOCs for an EID-Prefix. 
To publish its EID-Prefixes, an ETR periodically sends Map-Register 
messages to the Map-Server. A Map-Register message contains a list 
of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR 
when a Map-Server needs to forward a Map-Request to it. 
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When LISP+ALT is used as the mapping database, a Map-Server connects 
to the ALT network and acts as a "last-hop" ALT-Router. Intermediate 
ALT-Routers forward Map-Requests to the Map-Server that advertises a 
particular EID-Prefix, and the Map-Server forwards them to the owning 
ETR, which responds with Map-Reply messages. 


A Map-Resolver receives Encapsulated Map-Requests from its client 
ITRs and uses a mapping database system to find the appropriate ETR 
to answer those requests. On a LISP+ALT network, a Map-Resolver acts 
as a "first-hop" ALT-Router. It has Generic Routing Encapsulation 
(GRE) tunnels configured to other ALT-Routers and uses BGP to learn 
paths to ETRs for different prefixes in the LISP+ALT database. The 
Map-Resolver uses this path information to forward Map-Requests over 
the ALT to the correct ETRs. 


Note that while it is conceivable that a Map-Resolver could cache 
responses to improve performance, issues surrounding cache management 
will need to be resolved so that doing so will be reliable and 
practical. As initially deployed, Map-Resolvers will operate only in 
a non-caching mode, decapsulating and forwarding Encapsulated Map 
Requests received from ITRs. Any specification of caching 
functionality is left for future work. 


Note that a single device can implement the functions of both a 
Map-Server and a Map-Resolver, and in many cases the functions will 
be co-located in that way. 


Detailed descriptions of the LISP packet types referenced by this 
document may be found in [RFC6830]. 


4. Interactions with Other LISP Components 
4.1. ITR EID-to-RLOC Mapping Resolution 


An ITR is configured with one or more Map-Resolver addresses. These 
addresses are "Locators" (or RLOCs) and must be routable on the 
underlying core network; they must not need to be resolved through 
LISP EID-to-RLOC mapping, as that would introduce a circular 
dependency. When using a Map-Resolver, an ITR does not need to 
connect to any other database mapping system. In particular, the ITR 
need not connect to the LISP+ALT infrastructure or implement the BGP 
and GRE protocols that it uses. 


An ITR sends an Encapsulated Map-Request to a configured Map-Resolver 
when it needs an EID-to-RLOC mapping that is not found in its local 
map-cache. Using the Map-Resolver greatly reduces both the 
complexity of the ITR implementation and the costs associated with 
its operation. 
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In response to an Encapsulated Map-Request, the ITR can expect one of 
the following: 


o An immediate Negative Map-Reply (with action code of 


"Natively-Forward", 15-minute Time to Live (TTL)) from the 
Map-Resolver if the Map-Resolver can determine that the requested 
EID does not exist. The ITR saves the EID-Prefix returned in the 


Map-Reply in its cache, marks it as non-LISP-capable, and knows 
not to attempt LISP encapsulation for destinations matching it. 


o A Negative Map-Reply, with action code of "Natively-Forward", from 
a Map-Server that is authoritative for an EID-Prefix that matches 
the requested EID but that does not have an actively registered, 
more-specific ID-prefix. In this case, the requested EID is said 
to match a "hole" in the authoritative EID-Prefix. If the 
requested EID matches a more-specific EID-Prefix that has been 
delegated by the Map-Server but for which no ETRs are currently 
registered, a 1-minute TTL is returned. If the requested EID 
matches a non-delegated part of the authoritative EID-Prefix, then 
it is not a LISP EID and a 15-minute TTL is returned. See 
Section 4.2 for discussion of aggregate EID-Prefixes and details 
of Map-Server EID-Prefix matching. 


o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 
possibly from a Map-Server answering on behalf of the ETR. See 
Section 4.4 for more details on Map-Resolver message processing. 


Note that an ITR may be configured to both use a Map-Resolver and to 


participate in a LISP+ALT logical network. In such a situation, the 
ITR should send Map-Requests through the ALT network for any 
EID-Prefix learned via ALT BGP. Such a configuration is expected to 


be very rare, since there is little benefit to using a Map-Resolver 
if an ITR is already using LISP+ALT. There would be, for example, no 
need for such an ITR to send a Map-Request to a possibly non-existent 
EID (and rely on Negative Map-Replies) if it can consult the ALT 
database to verify that an EID-Prefix is present before sending that 
Map-Request. 


4.2. EID-Prefix Configuration and ETR Registration 


An ETR publishes its EID-Prefixes on a Map-Server by sending LISP 
Map-Register messages. A Map-Register message includes 
authentication data, so prior to sending a Map-Register message, the 
ETR and Map-Server must be configured with a shared secret or other 
relevant authentication information. A Map-Server’s configuration 
must also include a list of the EID-Prefixes for which each ETR is 
authoritative. Upon receipt of a Map-Register from an ETR, a 
Map-Server accepts only EID-Prefixes that are configured for that 
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ETR. Failure to implement such a check would leave the mapping 
system vulnerable to trivial EID-Prefix hijacking attacks. As 
developers and operators gain experience with the mapping system, 
additional, stronger security measures may be added to the 
registration process. 


In addition to the set of EID-Prefixes defined for each ETR that may 
register, a Map-Server is typically also configured with one or more 
aggregate prefixes that define the part of the EID numbering space 
assigned to it. When LISP+ALT is the database in use, aggregate 
EID-Prefixes are implemented as discard routes and advertised into 
ALT BGP. The existence of aggregate EID-Prefixes in a Map-Server’s 
database means that it may receive Map Requests for EID-Prefixes that 
match an aggregate but do not match a registered prefix; Section 4.3 
describes how this is handled. 


Map-Register messages are sent periodically from an ETR to a 
Map-Server with a suggested interval between messages of one minute. 
A Map-Server should time out and remove an ETR’s registration if it 
has not received a valid Map-Register message within the past 

three minutes. When first contacting a Map-Server after restart or 
changes to its EID-to-RLOC database mappings, an ETR may initially 
send Map-Register messages at an increased frequency, up to one every 
20 seconds. This "quick registration" period is limited to 

five minutes in duration. 


An ETR may request that a Map-Server explicitly acknowledge receipt 
and processing of a Map-Register message by setting the 
"want-map-notify" (M-bit) flag. A Map-Server that receives a 
Map-Register with this flag set will respond with a Map-Notify 
message. Typical use of this flag by an ETR would be to set it for 
Map-Register messages sent during the initial "quick registration" 
with a Map-Server but then set it only occasionally during 
steady-state maintenance of its association with that Map-Server. 
Note that the Map-Notify message is sent to UDP destination port 
4342, not to the source port specified in the original Map-Register 
message. 


Note that a one-minute minimum registration interval during 
maintenance of an ETR-Map-Server association places a lower bound on 
how quickly and how frequently a mapping database entry can be 
updated. This may have implications for what sorts of mobility can 
be supported directly by the mapping system; shorter registration 
intervals or other mechanisms might be needed to support faster 


mobility in some cases. For a discussion on one way that faster 
mobility may be implemented for individual devices, please see 
[LISP-MN]. 
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An ETR may also request, by setting the "proxy Map-Reply" flag 
(P-bit) in the Map-Register message, that a Map-Server answer 
Map-Requests instead of forwarding them to the ETR. See [RFC6830] 
for details on how the Map-Server sets certain flags (such as those 
indicating whether the message is authoritative and how returned 
Locators should be treated) when sending a Map-Reply on behalf of an 
ETR. When an ETR requests proxy reply service, it should include all 
RLOCs for all ETRs for the EID-Prefix being registered, along with 
the routable flag ("R-bit") setting for each RLOC. The Map-Server 
includes all of this information in Map-Reply messages that it sends 
on behalf of the ETR. This differs from a non-proxy registration, 
since the latter need only provide one or more RLOCs for a Map-Server 
to use for forwarding Map-Requests; the registration information is 
not used in Map-Replies, so it being incomplete is not incorrect. 


An ETR that uses a Map-Server to publish its EID-to-RLOC mappings 
does not need to participate further in the mapping database 
protocol(s). When using a LISP+ALT mapping database, for example, 
this means that the ETR does not need to implement GRE or BGP, which 
greatly simplifies its configuration and reduces its cost of 
operation. 


Note that use of a Map-Server does not preclude an ETR from also 
connecting to the mapping database (i.e., it could also connect to 
the LISP+ALT network), but doing so doesn’t seem particularly useful, 
as the whole purpose of using a Map-Server is to avoid the complexity 
of the mapping database protocols. 


4.3. Map-Server Processing 


Once a Map-Server has EID-Prefixes registered by its client ETRs, it 
can accept and process Map-Requests for them. 


In response to a Map-Request (received over the ALT if LISP+ALT is in 
use), the Map-Server first checks to see if the destination EID 
matches a configured EID-Prefix. If there is no match, the 
Map-Server returns a Negative Map-Reply with action code 
"Natively-Forward" and a 15-minute TTL. This may occur if a Map 
Request is received for a configured aggregate EID-Prefix for which 
no more-specific EID-Prefix exists; it indicates the presence of a 
non-LISP "hole" in the aggregate EID-Prefix. 


Next, the Map-Server checks to see if any ETRs have registered the 
matching EID-Prefix. If none are found, then the Map-Server returns 
a Negative Map-Reply with action code "Natively-Forward" anda 
1-minute TTL. 
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If any of the registered ETRs for the EID-Prefix have requested proxy 
reply service, then the Map-Server answers the request instead of 
forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, 
and other information learned through the registration process. 


If none of the ETRs have requested proxy reply service, then the 
Map-Server re-encapsulates and forwards the resulting Encapsulated 
Map-Request to one of the registered ETRs. It does not otherwise 
alter the Map-Request, so any Map-Reply sent by the ETR is returned 
to the RLOC in the Map-Request, not to the Map-Server. Unless also 
acting as a Map-Resolver, a Map-Server should never receive 
Map-Replies; any such messages should be discarded without response, 
perhaps accompanied by the logging of a diagnostic message if the 
rate of Map-Replies is suggestive of malicious traffic. 


4.4. Map-Resolver Processing 


Upon receipt of an Encapsulated Map-Request, a Map-Resolver 
decapsulates the enclosed message and then searches for the requested 
EID in its local database of mapping entries (statically configured 
or learned from associated ETRs if the Map-Resolver is also a 
Map-Server offering proxy reply service). If it finds a matching 
entry, it returns a LISP Map-Reply with the known mapping. 


If the Map-Resolver does not have the mapping entry and if it can 
determine that the EID is not in the mapping database (for example, 
if LISP+ALT is used, the Map-Resolver will have an ALT forwarding 
table that covers the full EID space), it immediately returns a 
negative LISP Map-Reply, with action code "Natively-Forward" and a 
15-minute TTL. To minimize the number of negative cache entries 
needed by an ITR, the Map-Resolver should return the least-specific 
prefix that both matches the original query and does not match any 
EID-Prefix known to exist in the LISP-capable infrastructure. 


If the Map-Resolver does not have sufficient information to know 
whether the EID exists, it needs to forward the Map-Request to 
another device that has more information about the EID being 
requested. To do this, it forwards the unencapsulated Map-Request, 
with the original ITR RLOC as the source, to the mapping database 
system. Using LISP+ALT, the Map-Resolver is connected to the ALT 
network and sends the Map-Request to the next ALT hop learned from 
its ALT BGP neighbors. The Map-Resolver does not send any response 
to the ITR; since the source RLOC is that of the ITR, the ETR or 
Map-Server that receives the Map-Request over the ALT and responds 
will do so directly to the ITR. 
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4.4.1. Anycast Map-Resolver Operation 


A Map-Resolver can be set up to use "anycast", where the same address 
is assigned to multiple Map-Resolvers and is propagated through IGP 
routing, to facilitate the use of a topologically close Map-Resolver 
by each ITR. 


Note that Map-Server associations with ETRs should not use anycast 
addresses, as registrations need to be established between an ETR and 
a specific set of Map-Servers, each identified by a specific 
registration association. 


5. Open Issues and Considerations 


There are a number of issues with the Map-Server and Map-Resolver 
design that are not yet completely understood. Among these are: 


o Constants, such as those used for Map-Register frequency, 
retransmission timeouts, retransmission limits, Negative Map-Reply 
TTLs, et al. are subject to further refinement as more experience 
with prototype deployment is gained. 


o Convergence time when an EID-to-RLOC mapping changes, and 
mechanisms for detecting and refreshing or removing stale, cached 
information. 


o Deployability and complexity tradeoffs of implementing stronger 
security measures in both EID-Prefix registration and Map-—Request/ 
Map-Reply processing. 


o Requirements for additional state in the registration process 
between Map-Servers and ETRs. 


A discussion of other issues surrounding LISP deployment may also be 
found in Section 15 of [RFC6830]. 


The authors expect that experimentation on the LISP pilot network 
will help answer open questions surrounding these and other issues. 
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6. 


Security Considerations 


The 2-way LISP header nonce exchange documented in [RFC6830] can be 
used to avoid ITR spoofing attacks. 


To publish an authoritative EID-to-RLOC mapping with a Map-Server, an 
ETR includes authentication data that is a hash of the message using 
a pair-wise shared key. An implementation must support use of 
HMAC-SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 
[RFC6234] (SHA-256 truncated to 128 bits). 


During experimental and prototype deployment, all authentication key 
configuration will be manual. Should LISP and its components be 
considered for IETF standardization, further work will be required to 
follow the BCP 107 [RFC4107] recommendations on automated key 
management. 


As noted in Section 4.2, a Map-Server should verify that all 
EID-Prefixes registered by an ETR match the configuration stored on 
the Map-Server. 


The currently defined authentication mechanism for Map-Register 
messages does not provide protection against "replay" attacks by a 
"man-in-the-middle". Additional work is needed in this area. 


[LISP-SEC] defines a proposed mechanism for providing origin 
authentication, integrity, anti-replay protection, and prevention of 
man-in-the-middle and "overclaiming" attacks on the Map-Request/ 
Map-Reply exchange. Work is ongoing on this and other proposals for 
resolving these open security issues. 


While beyond the scope of securing an individual Map-Server or 
Map-Resolver, it should be noted that a BGP-based LISP+ALT network 
(if ALT is used as the mapping database infrastructure) can take 
advantage of standards work on adding security to BGP. 
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